Hey @Debasish-87, thanks for looking into this. The feature request in #3826 is valid, and including namespace/pod labels in Prometheus metrics is standard practice in the Kubernetes ecosystem (see Prometheus instrumentation best practices).

However, I believe this PR doesn't address the issue. It adds k8s_ns_name and k8s_pod_name labels hardcoded to "n/a", which provides no useful information. Constant-value labels violate Prometheus best practices since labels should distinguish time series.

The underlying problem is that rules_matches_total is currently a per-rule aggregate counter. The stats_manager::on_event() only receives a const falco_rule& and has no access to per-event data. That said, the sinsp_evt* IS available at match time (in falco_engine::process_event()), and falco_outputs::handle_event() already resolves all output fields (including k8s.ns.name, k8s.pod.name from the container plugin) into a map<string, string>. So the data is there, it just doesn't reach the stats_manager.

A more generic solution would be to allow users to configure which output fields should be promoted to Prometheus labels on rules_matches_total. Something like:

metrics:
   rules_counters_extra_labels:
     - k8s.ns.name
     - k8s.pod.name

This would require changes to the stats_manager to track per-(rule, label_values) counters instead of just per-rule counters, but the architecture supports it since the event data is available at the right point in the pipeline.

This is a larger change than what this PR proposes, and I'm still unsure if this is a good idea. I'd suggest opening a design discussion for this approach. wdyt? 🤔

cc @falcosecurity/core-maintainers